Release 10.1A: OpenEdge Development:
Progress Dynamics Repository Reference

gsc_object_type table — gscot

This table defines the types of programs supported. A record must exist for the various support templates, such as Object Controller, Menu Controller, OpenEdge SmartFolder™, OpenEdge SmartBrowser™, OpenEdge SmartViewer™, and OpenEdge SmartDataObjects™.

When objects are created, they must be assigned an object type.

Table 10–3 lists the table’s FLA, fields, and foreign keys.

Table 10–3: gsc_object_type table information 

Table FLA	Fields (data type)	Foreign keys
gscot	object_type_obj (Decimal) object_type_code (Character) object_type_description (Character) disabled (Logical) layout_supported (Logical) deployment_type (Character) static_object (Logical) class_smartobject_obj (Decimal) extends_object_type_obj (Decimal) cache_on_client (Logical) custom_object_type_obj (Decimal)	object_type_obj

Table 10–4 gives details of the table’s indexes.

Table 10–4: gsc_object_type index information 

Index name	Elements	Type
XPKgsc_object_type	object_type_obj	Primary Unique
XAK1gsc_object_type	object_type_code	Unique
XIE1gsc_object_type	object_type_description	Nonunique
XIE2gsc_object_type	extends_object_type_obj	Nonunique
XIE3gsc_object_type	class_smartobject_obj	Nonunique
XIE4gsc_object_type	custom_object_type_obj	Nonunique

The object type is used as a grouping mechanism for security. This enables restrictions to be created for certain types of objects, rather than having to set up security for every object.

A recursive join exists for the object type to facilitate definite object type hierarchies (class hierarchies). This is useful for attribute inheritance at multiple levels of object type. For example, an object type could be defined for a fill-in, then a child of this might be an integer fill-in, and a child of that might be an object id.

To support customizations for object types (classes), you can specify a custom_object_type_obj to identify an additional class structure to include as part of another class, such as to add additional custom attributes and class super procedures. This makes it easier to add customizations to a class in the middle of the hierarchy without having to modify the hierarchy itself. You would not have to change the extends_object_type_obj of the subclasses to point at the new custom class.

A specified custom class is added below the customized class. If you customize the data class with a custom class datacustom, then at run time datacustom is added as a subclass of data. It overrides and extends the behavior of all objects that further extend the data class. This also means that all classes below the data class would also automatically extend the custom class datacustom rather than data. So datacustom ends up in the middle of the class hierarchy.

The custom class itself can include a structure below it to provide multiple levels of customization. All of the customizations are inserted below the class, and classes that previously extended the class will instead extend the class at the bottom of the customized classes. For example, if the custom class datacustom included an additional subclass, datacustom2 that extends datacustom, then the subclasses of the original class, data, point at datacustom2, which points at datacustom, which then points back at the original class, data.

The field custom_object_type_obj is specified in the deployment datasets exclude field list so that it is never overwritten as part of deploying changes to the class structure. This avoids the loss of the customizations with future upgrades.